The clinical documentation systems used in connection with many modern electronic medical records (EMRs) include both user interface elements for entering discrete data into EMRs and user interface elements for entering free-form text into EMRs. Examples of common user interface elements for entering discrete data into EMRs include checkboxes and radio buttons to indicate the presence of absence of problems, complications, conditions of family members, and tests performed during a physical examination; date selection controls to capture the onset or end of certain events (e.g., the date on which pain started, when a family member died, or on which treatment began or ended); and dropdown lists to indicate current and past medications. The most common example of a user interface element for entering free-form text into EMRs is a text field.
Although it might seem that it would be desirable to design clinical documentation systems to include only user interface elements for entering discrete data elements in order to eliminate ambiguity and subjectivity from such data entry, typically it is not possible or desirable to represent all possible inputs using discrete user interface elements, even for narrowly-defined subsets of a clinical document. One reason for this is that discrete user interface elements are not capable of capturing uncommon events, conditionality between multiple observations, uncertainty in observations that cannot accurately be represented by a binary parameter value (e.g., “the patient exhibits signs of X”), and causality. More generally, requiring all EMR data to be entered using discrete UI elements would fail to capture the story of a patient and the thought process of the authoring physician in a way that is both memorable and interpretable by the authoring or other physicians.
As a result, clinical documentation systems typically allow free-form text to be entered into EMRs. For example, it is common for such systems to include a free-form text entry field alongside each logical grouping of discrete user interface elements. For example, a free-form text entry field may be provided for a “History of Present Illness” grouping of discrete user interface elements, another free-form text entry field may be provided for a “Family History” grouping of discrete user interface elements, and yet another free-form text entry field may be provided for a “Physical Examination” grouping of discrete user interface elements.
The resulting graphical user interface includes both user interface elements for receiving discrete data input and user interface elements for receiving free-form text input. As a consequence, the underlying data model into which data received using the graphical user interface is stored is also a hybrid of discrete data and free-form text data.
There are at least two problems with such an EMR system:                (1) Discrete data entry fields tend to be much less user friendly than free-form text entry fields. For example, a typical data entry form for a physical examination may contain hundreds of checkboxes and other discrete data entry user interface elements. It can be difficult and time-consuming to find the right checkboxes to check, in comparison to merely typing or dictating a free-form text description of the same information. As a result, physicians or others who enter data into such an EMR system may either accept reduced productivity and data fidelity by entering data into the discrete data fields, or bypass the discrete data fields and just enter free-form text into the corresponding free-form text fields and thereby forfeit the benefits of the discrete data fields.        (2) It is generally not possible to ensure consistency between the data contained in a free-form text field and data contained in the corresponding discrete data fields. For example, consider the case in which one set of discrete data fields contain fields to capture palliative care instructions for a patient. Associated with such discrete data fields may be a free-form text entry field. If the physician chooses to enter instructions (e.g., a “Do Not Resuscitate” order) into the free-form text entry field and leaves the discrete data fields blank, then the information in the free-form text entry field will not be reflected in the discrete data fields. If the contents of the discrete data fields are used to drive a clinical workflow, then such a workflow will not be triggered if the text entry field contains data but the discrete data fields are empty.        
There is, however, substantial value in the discrete data elements, such as for automating common care workflows and for use in decision support processes. One way to address the problems described above is to abstract information contained in free form text fields, to reconcile the abstracted information with the last known state of the discrete data elements, and to let the user verify the reconciled data state as part of the free-form text input. One drawback of this approach is that to perform reconciliation, decisions may need to be made regarding the appropriate representation of the free-form text data within the discrete data model. Any errors in this process may need to be resolved by the user using a user interface that essentially mirrors or is identical to the user interface that is used for discrete data entry. As a result, the cost of implementing such a system may be substantial if it is implemented as an add-on to an existing third-party EMR system, due to the need to duplicate essential parts of the discrete data entry user interface for use in the reconciliation review process.